home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13250 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB

  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.eiffel,comp.lang.c,comp.lang.c++,comp.object,comp.software-eng
  4. Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
  5. Date: 24 Mar 1996 07:20:32 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4j3p80INN567@keats.ugrad.cs.ubc.ca>
  8. References: <1995Jul3.034108.4193@rcmcon.com> <31545B86.4CC0@iadfw.net> <4j26cn$gh7@solutions.solon.com> <3154A548.71FF@iadfw.net>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <3154A548.71FF@iadfw.net>, Larry Weiss  <lfw@iadfw.net> wrote:
  12.  
  13. >OK, now we are in sync.     I just wanted to know if anyone who used to
  14. >do that sort of thing was upset with the implementations that choose to
  15. >use inline techniques at code generation time for one or more standard
  16. >library functions.
  17.  
  18. I would be very upset if the implementation did not allow me to turn it of,
  19. like the -fno-builtin option of GCC. Sometimes it is very useful to write your
  20. own malloc() (though I don't know of any implementation that inlines malloc()
  21. calls).
  22.  
  23. >Looking at it another way, until the C Standard was published, I just looked
  24. >at the vendor supplied library as a popular example of how one might go about
  25. >interfacing with a file system, or manipluating strings, etc.   I didn't
  26. >think of the library as a formal part of the C language.   Now, of course
  27.  
  28. Neither does the K&R2: this I think is a major flaw in the otherwise great
  29. book. It never makes clear the concept that the standard library is a component
  30. of the language. In fact, it claims the opposite:
  31.  
  32.     The standard library is not part of the C language proper, but an
  33.     environment that supports standard C will provide the function
  34.     declarations and type and macro definitions of this library.
  35.     (beginning of Appendix B).
  36.  
  37. >the standard library is a well defined component of the C language, with
  38. >the implementation able to know all sorts of things about the semantics of
  39. >each library function.     C suddenly became much larger and complex with the
  40. >publication of the Standard, in my mind.     It would have been nice if the
  41.  
  42. Not at all; that's the beauty of it! All of the standard library functions can
  43. be implemented by essentially adding a compatible library and headers to a
  44. ``freestanding'' implementation. The standard doesn't _require_ that you inline
  45. any of the functions or that the compiler be aware of special semantics, but
  46. the implementor has the freedom to do this. This is why the inclusion of
  47. appropriate headers is still required when you use standard functions---for
  48. example, you must include <stdlib.h> to call malloc(), or <stdio.h> to use
  49. printf().  If the compiler were really required to know malloc or printf a
  50. priori, the need for a header file could easily have been dropped long ago.
  51. -- 
  52.  
  53.